Hi @cyppe,

Thanks for the PR I'm not really sure if it is already time to add in such layer of caching before we find out the details. Atm caching isn't possible for a lot of rules, that's okay. But I think we want to make it possible for nested data classes/collections since you'll probably have a lot of them. So without support for that it feels like adding a lot of code we need to maintain without a lot of extra gains.

So that open up the question is it possible to do this for data classes/collections and extended even morphable properties(which always are dataclasses for now btw). I think so but we need to rewrite your PR differently. Atm we're calculating the rules when validating but why not do this in advance? We've got a system with DataProperties and Dataclasses in place which can be completely cached once deploying. So wouldn't it be possible to cache rules on the DataClass (heck even the DataProperty if that makes things easier?).

Then we could also solve the issue with the morphable properties since it will always be a data object and thus we'll probably have the rules available somewhere.

As an added benefit, since we would cache everything nothing stops us from using cached rules for individual data objects not in a collection. That should make things even faster.

As for the $potentiallyUnsafeAttributes let's not do it like that but introduce an interface UncachableValidationAttribute and tag all attributes which arent't cacheable. Easier to read and maintain.

This would be a really cool feature but to do it good it will require a bit of work. Feel free to try it out, otherwise it something on my list to once take a look at but not sure when 😄